所以在前面 Gitlab 的篇幅中講了一些 best practice 的觀念後，接下來又要講新的東西，這東西 kubernetes 其實網路上很多，如果有問題也可以用 ChatGPT就可以問出你要的答案，但是這篇主要會提到對於一個 Machine Learning Engineer 的影響跟使用情境

Why using EKS to build Cluster?

首先，EKS 簡單來講就是 AWS 上面的 k8s ，大概很多人都會提問 K8s 自己架設就好啦，為什麼要放在 AWS EKS 上面，其主要有幾點

• Management : 管理上面可以提供很大的幫助，因當系統故障或service 無法起來，甚至pods 無法部屬上去或掛掉的時候，如果再 on-premise 的時候，你的 service 基本上就掛掉了，甚至卡住log 根本沒辦法呈現錯誤資訊
• Integrate Service : 在 eks 上面可以很快速的把一些 Security Group 或者 EC2 的部分直接整合再一起，需要計算資源的時候就直接啟動一個EC2 整合進去eks 上面，就不需要額外的設定才有辦法整合，這部分真的很方便
• Auto Scaler : 承上的整合的部分，就是因為 EC2 可以快速的擴增跟縮減，因此對於資源的調度上十分彈性，隨時可以增加跟減少，我這邊就曾經一次開啟100個 EC2 來做短時間的計算，真的算是蠻方便的
• Application Loading Balancer : 至於ALB的部份 k8s 已經把service 那層在獨立出來一個 component 叫做 ingress，這邊可以設定使用 service name 來找 ClusterIP ，而在EKS 會直接Expose 一個網址，然後套用設定好的 Security Group 所以在限定的IP下來存取服務。這部分就是 ML API 通常會使用到不同的 API Entpoint 這邊就可以來實作 Endpoint 的部分。
• Infrastructure as Code : 這就不需要再另外多說了，對一個 Maintainer來講的友善環境！

Why DO NOT chose Lambda, EC2, Batch, Sagemaker

• Lambda : 對於計算資源來講，其實 Lambda Function 也是一個很棒的 AWS service ，甚至可以當作 Endpoint 來提供服務使用，但是他計算的時間跟資源其實都有限制，沒辦法應付很多需要 量大計算 的情境，只能做基本的 Routing 或者簡單的身份驗證，呼叫DynamoDB等等的
• 而 EC2 上面可以直接使用 Image 把整個環境丟到 EC2 上面，但是問題是 EC2 的計算資源畢竟只有那麼多，如果單純只在上面做計算的話，真的是完完全全失去使用 AWS Availabliity 的特性， 這種問題通常會發生在剛上雲的工程師上面 ，就是開個EC2 然後裡面架設service ，雖然這個是AWS 提供的 Tourial 沒錯，但是請記住 EC2 就是一個 computing resource ，所以不要期待EC2 可以給你什麼彈性
• 剛剛嘴 EC2 沒有計算資源那計算資源用 Batch 可以了吧？沒錯，這確實可以，但是 Batch 也有限制，例如說他沒有像是 Kubelet 這個東西，可以讓 Manager Node 可以管控 Node 的狀況，這樣講不太對，應該是在 AWS 那一層你沒辦法控制 Kubelet ，所以他也給你大量的 Node，但是Node 每個都是獨立的
• AWS Sagemaker 也不錯，但是他就是把問題丟到Batch 上面處理，所以只是包了一層皮的 Batch (以計算資源來講），但是他整合很多 MLOps 裡面需要觀察或者 Monitor 的資訊，如果沒有特殊需求其實也很夠

Why K8s ?

其實 K8s 得管理彈性跟 Pod 的搬移，還有網路層面的 Routing ，確實會讓很多神奇的鬼故事減少，管理者也方便處理很多異常的狀況，真的是偉大的發明，也因為如此，所以K8s 對於 MLE 來講也是省去很多設定的問題。

當然還是有很多其他的設定，但是這些設定都是免去後面不斷地設定。

剩下的就大概是 K8s 的特性了吧，我就不多說了，網路上跟 ChatGPT都會告訴你。